The \gloss{hive protocol} enables nodes to exchange information about other peers that are relevant to them in order to bootstrap their connectivity  (see \ref{sec:bootstrapping}) . The information communicated are both overlay and underlay addresses of the known remote peers (see  \ref{spec:format:bzzaddress}). The overlay address serves to select peers to achieve the connectivity pattern needed for the desired network topology. Underlay address is needed to establish the peer connections by dialing selected peers.

\subsection{Streams and messages \statusgreen}


The protocol specifies one stream with two messages:

\begin{definition}[Hive protocol messages]\label{def:hive-messages}

\begin{lstlisting}
// /swarm/hive/1.0.0/peers
syntax = "proto3";

package hive;

message Peers {
    repeated BzzAddress peers = 1;
}

message BzzAddress {
    bytes Underlay = 1;
    bytes Signature = 2;
    bytes Overlay = 3;
}

\end{lstlisting}
\end{definition}

During the lifetime of connection, nodes can broadcast newly received peers to their peers. This is done by sending the \lstinline{Peers} message over the \\\lstinline{/swarm/hive/1.0.0/peers} stream.

Upon receiving a peers message, nodes are meant to store the peer information in their \gloss{address book}, i.e., a data structure containing info about peers known to the node. The address book is meant to be used to suggest peers  to a connectivity manager according to a connection strategy (\ref{spec:strategy:connection}) in order to bootstrap kademlia topology (\ref{sec:kademlia-connectivity}). The address book is meant to be persisted across sessions.

\subsubsection{Sending side}

A stream with the appropriate id is created and a \lstinline{Peers} message is sent over the stream. There is no response to this message. The sending node should wait for the receiving side to close its side of the stream, before closing the stream themselves and moving on.

\subsubsection{Receiving side}

When the stream is created, receiving node should wait for a \lstinline{Peers} message. After receiving the message, node should close its side of the stream to let the sender node know that the message was received, and move on with processing. If the new node was not known, it should also be forwarded to all connected peers closer to peer address then the node themselves.